Компания VMware выпустила VMware View Client for Android - клиентское приложение для смартфонов и планшетов с ОС Android, с помощью которого можно получить доступ к корпоративным ПК предприятия на базе инфраструктуры VMware View. На данный момент продукт находится в статусе Tech Preview, его можно загрузить через Android Market.
Основные возможности, которыми обладает VMware View Client для Android:
Поддержка VMware View 4.6 и более поздних версий.
Поддержка только протокола PCoIP для доступа к виртуальным ПК.
A new look and feel – View Client for Android сделан в новом стиле, в отличие от других клиентов VMware View.
Multiple broker support – если у вас есть более одного одного сервера VMware View Connection Server, вы можете получить доступ к любому из них.
Desktop Shortcuts – к четырем десктопам можно получить через ярлыки на рабочем столе смартфона или планшета.
Virtual trackpad – удобное управление мышью внутри рабочего стола виртуального ПК.
Custom keyboard toolbar – простой доступ к клавишам, которых нет в стандартной клавиатуре на Android .
Honeycomb 3.x support – клиент разработан специально для Android и поддерживает все новые версии этой ОС, включая 3.x на планшетах.
Custom gestures – удобный функционал вызова клавиатуры, скроллинга и т.п.
VMware View Security Server support (best experience) – для клиента не нужен VPN при использовании VMware View Security Server (то есть, трафик прокируется через него - не нужен прямой доступ к серверам ESX от клиента).
Background tasking – удобное переключение между виртуальным ПК и другими задачами Android.
Параллельно с релизом новой версии платформы виртуализации VMware vSphere 5 компания VMware объявила о выходе новых версий еще нескольких продуктов своей линейки для организации частных облаков. Один из них - VMware Site Recovery Manager 5, где появилось несколько полезных новых возможностей и улучшений.
Взглянем на общую картину улучшений:
Как мы видим, основных моментов, отличающих VMware SRM 5 от предыдущей версии, три - это репликация на уровне хостов VMware ESXi 5, возможность запланированных миграций и автоматизированный failback (восстановление на основную площадку с резервной после восстановления работы первой).
Рассмотрим сначала репликацию на уровне хоста (Host Based Replication):
Теперь нам предлагается 2 вида репликации в VMware Site Recovery Manager 5. Наиболее критичные виртуальные машины (Tier 1 apps) мы защищаем с помощью репликации на уровне дисковых массивов (а значит, это дорого), а менее критичные (Tier 2) мы защищаем с помощью Host Based Replication. Под менее критичными приложениями мы подразумеваем такие, у которых требования к точке восстановления составляют от 15 минут до 24 часов (именно для таких и применяется репликация).
Взглянем на репликацию в VMware Site Recovery Manager 5 поближе:
На каждом хосте VMware ESXi 5 у нас работает vSphere Replication Agent (VSR Agent), который передает все данные об изменении виртуальных дисков машин на резервный сайт в асинхронном режиме с некоторым интервалом. Наличие агента означает, что репликация на базе хоста будет работать только, начиная с VMware ESXi 5.
На резервном сайте работает vSphere Replication Server, который собирает данные об изменениях виртуальных дисков с основной площадки и применяет их к виртуальным машинам на хранилищах резервного сайта. Также на обеих площадках есть компонент vSphere Replication Management Server, который тесно интегрирован с vCenter и SRM и необходим для управления процессом репликации, а также чтобы управлять несколькими vSphere Replication Server, потому как какждый из них обслуживает около 100 машин.
Рассмотрим теперь новый рабочий процесс - Planned Migrations:
Теперь, помимо основного процесса DR Failover, в VMware SRM 5 есть процесс Planned migration (он входит в Recovery Plan). Он позволяет выключить виртуальные машины, синхронизировать хранилища и переместить виртуальные машины на резервную площадку. Поскольку машины выключаются корректно, они переезжают на резервную площадку без вреда для приложений и данных.
Данный процесс может быть полезен для обслуживания основного сайта, тестирования возможности восстановления и просто для переезда виртуальных машин на резервную площадку по необходимости. Ну и, по-сути, на практике его можно применять, когда команда основной площадки знает, что через некоторое время основной сайт будет выведен из строя и есть возможность машины на некоторое время остановить для миграции.
Ну и третье наиболее значимое нововведение VMware Site Recovery Manager 5 - Automated Failback:
Это та возможность, которую так долго ждали пользователи VMware SRM. Теперь в продукте есть механизм реализации двунаправленных миграций за счет автоматизации операций по переключению с резерва на основной сайт (Failback).
При инициации Failback, VMware SRM 5 взаимодействует с массивом, чтобы повернуть репликацию в обратную сторону, а затем выполняет Recovery Plan в обратном направлении в отношении основного сайта (то есть отдельный план восстановления для Failback не нужен).
Для данной возможности SRM 5 есть два ограничения:
основной сайт не должен измениться после восстановления (то есть там нельзя снова переустановить хосты ESXi)
эта функция не работает с vSphere Host Based Replication
Лицензирование VMware Site Recovery Manager 5
Ну и рассмотрим, что изменилось в лицензировании VMware Site Recovery Manager 5. У нас есть теперь два издания SRM - Standard и Enterprise, оба с одинаковым функционалом:
Как видно из таблицы, единственная разница - это то, что в издании SRM Standard есть ограничение на 75 виртуальных машин на одной площадке. Здесь отчетливо видно, что цена в $195 за виртуальную машину для издания Standard (а значит, и для среднего и малого бизнеса) - это попытка конкурировать с продуктом Veeam Backup and Replication 5, который еще со своей первой версии умеет делать репликацию виртуальных машин между площадками. Однако здесь совершенно понятно, что даже при 7 виртуальных машинах на двухпроцессорный хост (а это немного) - VMware SRM уже проигрывает по цене Veeam Backup and Replication (а в последнем есть помимо репликации еще много чего).
Маппинг лицензий существующих пользователей VMware Site Recovery Manager на пятую версию будет проходить так:
Обновление на VMware SRM 5 для пользователей с активной подпиской и поддержкой (SnS) происходит бесплатно. Все получают издание SRM Enterprise, однако есть нюанс: те, кто покупал SRM по процессорам хостов ESX / ESXi теперь получают лицензии по количеству виртуальных машин из расчета 5 лицензий на ВМ для одной купленной ранее лицензии на процессор (невыгодно, да, а что делать). Это потому, что VMware SRM уже достаточно давно лицензируется только по количеству защищаемых виртуальных машин.
Вот вкратце и все. Если у вас будет интерес к тому, чтобы мы подетальнее описали VMware Site Recovery Manager 5 - то сделаем технический обзор.
Компания VMware в июле 2011 года объявила о доступности новых версий целой линейки своих продуктов для облачных вычислений, среди которых находится самая технологически зрелая на сегодняшний день платформа виртуализации VMware vSphere 5.0.
Мы уже рассказывали об основном наборе новых возможностей VMware vSphere 5.0 неофициально, но сейчас ограничения на распространение информации сняты, и мы можем вполне официально рассказать о том, что нового для пользователей дает vSphere 5.
Сегодня, в 20-00 по московскому времени, состоится онлайн-мероприятие под названием "Raising the Bar, Part V", вести которое будет, в частности Пол Мориц, глава компании VMware. Вот по этой ссылке можно зарегистрироваться на мероприятие.
В этом вебкасте нам расскажут о VMware vSphere 5 и новых инициативах компании в сфере облачных вычислений (vCloud). Бонус - весьма вероятен синхронный перевод на русский язык.
Некоторым из вас должен быть знаком проект pfSense, который представляет собой разработку программного фаервола и роутера на базе дистрибутива FreeBSD. Это средство есть также в виде виртуального модуля (Virtual Appliance), которое можно импортировать в VMware vSphere в качестве уже готовой машины. Также Eric Sloof сделал его в в формате OVA.
Естественно, pfSense - это бесплатно и open source. Для продукта доступно огромное количество модулей, за счет которых можно расширять функционал.
У Duncan'а Epping'а появилась познавательная статья о том, как перенести ваш текущий сервер VMware vCenter 4.0, 32-битная версия которого еще была в VMware vSphere 4.0 на платформу 64-бит (начиная с 4.1) с сохранением всей иерархии объектов, задач и данных о производительности.
Во-первых, если вы скачаете пакет VIM (VMware Infrastructure Management) с дистрибутивом vCenter 4.1, в ISO-архиве вы найдете папку datamigration с файлом datamigration.zip:
Теперь вам нужно сделать следующие шаги:
1. Поднять новый VMware vCenter 4.1 64-bit.
2. Открыть этот datamigration.zip и скопировать его содержимое в папку datamigration на вашем 32-битном сервере vCenter 4.0.
3. Остановить службы vCenter Service, Update Management Service и vCenter Web Service.
4. Запустить backup.bat.
5. После завершения процесса бэкапа скопируйте всю папку datamigration на целевой хост vCenter 4.1 64-bit (в то же место).
6. Запустите install.bat.
Далее:
Подтвердите имя vCenter Server и нажмите Y
Укажите путь к установочным файлам vCenter
Укажите путь к установочным файлам VMware Update Manager (по умолчанию, тот же)
Высветится окошко о том, что базы данных будут восстановлены на новом сервере
Продится все это минут 15, после чего можно запускать vSphere Client и смотреть на новый сервер со всеми сохранившимися тасками, объектами, иерархией и т.п.
Если ваша компания является партнером VMware, то для вас интересная новость. На партнерском портале компании VMware в разделе Content появилось множество офлайновых демок продуктов, которые позволят вам, не устанавливая их, посмотреть на GUI, функционал и обучиться основным возможностям по работе с продуктом.
Тыркать такие демо - весьма познавательно, особенно учитывая тот факт, что многие из продуктов VMware вы никогда в глаза не видели и вряд ли увидите в ближайшем будущем. Например, вот как выглядит VMware vFabric Hyperic:
А вот так работа VMware vShield App с vCloud Director:
В последнее время появилось несколько интересных вещей, касающихся решения по виртуализации корпоративных ПК предприятия VMware View. Во-первых, обновился документ "PC-over-IP Protocol Virtual Desktop Network Design Checklist", в котором описаны основные лучшие практики по использованию протокола PCoIP для доступа к виртуальным десктопам. По-сути, это обязательный для прочтения документ для тех, кто использует доступ к ПК по протоколу PCoIP. Там очень много практических рекомендаций:
Во-вторых, появился клиент VMware View для настольной ОС Ubuntu с поддержкой протокола PCoIP. Клиент неофициальный - основные моменты по его установке и использованию описаны в статье "VMware View PCoIP on Ubuntu How to".
В-третьих, появилось интересное видео о перенаправлении пользовательских папок в виртуальных ПК VMware View:
В-четвертых, интересное и завораживающее видео "VMware View GPU assisted Virtual Desktop":
На сайте проекта VMware Labs очередная новая утилита - VMware Zimbra for Android (VZA). Это email-клиент и не только, который работает с серверами VMware Zimbra Collaboration Suite (ZCS) и Microsoft Exchange в качестве бэкэнда.
VZA работает с Microsoft Exchange 2003, 2007 и 2010, а также Zimbra Collaboration Suite 6.x and 7.x (в последнем случае доступны дополнительные возможности, такие как Briefcase, Saved Searches и т.д.). В качестве ОС телефона поддерживаются Android 2.x и 3.x.
Мы уже писали о некоторых расширенных настройках дисковой подсистемы серверов VMware ESX / ESXi, которые позволяют управлять доступом виртуальных машин к хранилищам VMFS. Сегодня постараемся описать еще несколько параметров:
Опишем еще несколько параметров Advanced Settings для категории Disk:
Disk.MaxLUN - это число (по умолчанию 256, т.е. ID от 0 до 255), опеделяющее максимальное количество томов, доступных серверу VMware ESX / ESXi.
Disk.MaskLUNs = "vmhba1:0:32-35;vmhba2:0:1,5,7-9" - это параметр, определяющий маскирование томов VMFS в SAN. В данном примере от хоста ESX / ESXi скрываются LUN с ID от 32 до 35 для HBA-адаптера vmhba1, а также LUN с ID 1,5,7,8,9 для адаптера vmhba2. Разделитель для адаптеров - точка с запятой.
Disk.SupportSparseLUN - эта настройка включена по умолчанию (значение 1), по желанию ее можно выставить в 0. Значение 1 означает, что на ESX / ESXi включена поддержка номеров LUN, идущих непоследовательно (например, 0,6 и 23). Если у вас все LUN идут по порядку, то можно отключить эту функцию, выставив значение 0. В этом случае будет тратиться немного меньше времени на сканирование всех LUN.
Disk.DiskMaxIOSize - с помощью этого параметра можно задать максимальный размер операции ввода-вывода (IO request). По умолчанию, сервер VMware ESX / ESXi поддерживает объем IO-запроса размером до 32767 KB, запросы большего объема разбиваются на части. Для некоторых хранилищ (это надо смотреть в документации) такой размер IO-запроса, генерируемый некоторыми приложениями может оказаться слишком большим и привести к снижению производительности. Поэтому можно уменьшить этот параметр, в зависимости от модели дискового массива. Более подробно описано в KB 1003469.
Disk.SchedQControlVMSwitches - по умолчанию, этот параметр равен 6. Он означает вот что. Когда у нас несколько виртуальных машин отдают свои IO к LUN, у нас вступает в игру параметр Disk.SchedNumReqOutstanding (а не глубина очереди адаптера), который определяет границу для виртуальных машин по одновременной отдаче команд ввода-вывода. Если эта граница превышена - наступает постановка команд в очередь. Но VMkernel должен перед этим обнаружить, что LUN использует несколько ВМ. Так вот Disk.SchedQControlVMSwitches определяет сколько раз должен VMkernel это обнаружить. А понимает он это только тогда, когда следующее IO приходит не от той машины, которая дала предыдущий IO. Надо понимать, что это значение может быть достигнуто не очень скоро, когда у нас есть одна высоконагруженная ВМ A на одном LUN, и там же есть низконагруженная по IO машина (B). И это хорошо, поскольку в таких окружениях не должно быть урезания по вводу-выводу для высоконагруженной ВМ.
Disk.SchedQuantum - по умолчанию, этот параметр равен 8. Он определяет число высокоприоритетных последовательных команд, которые идут к дисковому устройству. Последовательными командами считаются те, которые идут к расположенным рядом секторам диска. Что такое расположенные рядом сектора диска? Это те, которые (по умолчанию) находятся друг от друга на расстоянии не более 2000 секторов. Такие команды выполняются до 10 раз быстрее, чем с далекими секторами.
Disk.SectorMaxDiff - это и есть параметр, определяющий, что такое "близкие" секторы для предыдущего параметра. По умолчанию, он равен 2000.
Disk.SchedQControlSeqReqs - этот параметр (по умолчанию, 128) определяет число последовательных IO без переключений (т.е. последовательность команд только от одной ВМ), после которых счетчик Disk.SchedQControlVMSwitches будет сброшен в 0, а машина сможет использовать опять всю очередь адаптера. Этот параметр нужен для того, чтобы после всплеска нагрузки на ВМ B в первом примере, когда этот всплеск прекратится, ВМ A снова смогла получить в свое распоряжение всю очередь адаптера и дальше работать в интенсивном режиме без входа в игру параметра Disk.SchedNumReqOutstanding, который распределяет IO на LUN.
Воткнули? Нет? Тогда еще раз перечитывайте статью Duncan'а. А еще один блоггер, Andy Grant, нарисовал замечательную картинку (кликабельно):
Мы уже вам надоели с необходимостью подготовки миграции вашей виртуальной инфраструктуры VMware vSphere с хостов ESX на ESXi (поскольку vSphere 5 будет только на базе ESXi), но, все-таки, пролжим деятельность в этом направлении.
Мы уже писали о средстве PXE Manager for vCenter, имеющемся на сайте проекта VMware Labs. Оно нужно для автоматизации развертывания хостов VMware ESXi (Stateless или Stateful) по PXE. Говорят, что утилита войдет в состав VMware vSphere 5. Работает оно только с хостами VMware ESXi, но в версии 4.1 Update 1 утилита получила функцию по миграции хостов ESX на ESXi:
Теперь в утилиту можно добавить хост ESX (предварительно вы уже должны создать образ ESXi):
А далее просто выбрать пункт "Convert this ESX Server to VMware ESXi Server". Дальнейший процесс миграции со скриптом постконфигурации описан в статье Andy Grant "PXE Manager Howto: Converting ESX hosts to ESXi".
Как знают пользователи VMware vSphere, в версии платформы 4.1 появилась новая возможность по управлению приоритетами ввода-вывода виртуальных машин для хранилищ на уровне кластера под названием Storage IO Control (SIOC). Но эта функциональность доступна только в издании vSphere Enterprise Plus, что оставляет множество пользователей за бортом.
В рамках одного хост-сервера VMware ESX / ESXi есть механизм по управлению приоритетами ВМ для хранилищ с помощью Disk Shares (в настройках ВМ). Однако эти приоритеты могут быть заданы только в относительных значениях, что тоже в некоторых случаях неудобно.
В версии VMware vSphere 4.1 появилась возможность задать параметры ограничения ввода-вывода для конкретных ВМ с помощью абсолютных значений (в числе операций в секунду - IOPS и в пропускной способности в секунду - MBps). Это может пригодиться для отдельных виртуальных машин, для которых есть риск "забивания" канала к системе хранения.
Как можно эти параметры добавлять:
Нажмите Edit Settings для выключенной виртуальной машины.
Перейдите на вкладку Options.
В категории Advanced: General нажмите кнопку Configuration Parameters.
Нажмите Add Row.
Далее можно добавить 2 параметра (обратите внимание, что они задаются для каждого виртуального диска):
sched.<diskname>.throughputCap = <value><unit>
Например:
sched.scsi0:0.throughputCap = 10KIOps
sched.<diskname>.bandwidthCap = <value><unit>
Например:
sched.scsi0:0.bandwidthCap = 10KBps
В качестве значений можно использовать буквы K (KBps или KIOps), M (MBps или MIOps) и G (GBps или GIOps). Подробнее в KB 1038241.
По наблюдениям автора, если задать оба параметра для виртуального диска, они будут проигнорированы хост-сервером. А если для каждого диска одной ВМ задать определенные лимиты, то для каждого из этих дисков лимит установится как сумма для двух (то есть, если мы поставим 100IOps и 50IOps, лимит для каждого диска станет 150IOps).
Напоминаю, что работает это только, начиная с VMware vSphere 4.1 (и для ESX, и для ESXi).
Пока все обсуждают то, что из Citrix ушли ключевые люди, а 12 июля VMware объявит о своей платформе VMware vSphere 5, мы расскажем о другом.
Хорошая новость для тех, кому необходимы средства для защиты инфраструктуры виртуализации VMware vSphere. Как многие знают, есть такое семейство продуктов VMware vShield, среди которых есть средства для обеспечения безопасности виртуальных машин, хост-серверов ESX / ESXi и периметра датацентра.
Теперь суть новой промо-акции. Любой пользователь VMware, приобретающий продукт VMware vSphere до 15 сентября 2011 года, получает бесплатно 50 лицензий на VMware vShield Data Security. Кстати, не очень понятно пока, какие именно компоненты vShield включены в промо-пакет, ведь как такого продукта VMware vShield Data Security еще нет, он выйдет несколько позже. При этом по данному промо, к пакету идет бесплатно поддержка и подписка на обновления на 1 год (SnS).
Исключение из акции составляют пакеты ПО VMware vSphere Essentials и VMware vSphere Essentials Plus, которые как всегда в пролете.
Список парт-номеров и названия продуктов, участвующих в акции, приведен здесь. Так что не забывайте задать вопрос своему поставщику VMware про данную акцию.
Мы уже писали об утилите VDI Sizing Tool от отчественного разработчика Василия. Она позволяет сымитировать нагрузку на виртуальные ПК предприятия (VMware View или Citrix XenDesktop) с помощью специальных агентов и измерить производительность решения (старт приложений, создание RDP-сессии и т.д.).
Недавно вышла версия VDI Sizing Tool 0.2. В новой версии утилиты появилась поддержка VMware View Client для протоколов RDP и PCoIP. А
на сайте автора появилась статья про сравнение потребления ресурсов
протоколами PCoIP и RDP:
В документе детально описана концепция Dynamic Memory, технологии, появившейся в Microsoft Windows Server 2008 R2 SP1, рассмотрены варианты ее применения и настройки, а также даны лучшие практики по ее использованию в производственной среде. Документ весьма понятный и очень нужный для администраторов Hyper-V.
Второе - несколько интересных документов от Veeam Software, выпускающей продукт номер один Veeam Backup and Replication 5 для создания систем резервного копирования VMware vSphere. Документы написаны известными блоггерами, давно пишущими о виртуализации на базе VMware.
VMware Recovery: 77x Faster! - интересный документ о практическом применении новейших технологий в продукте Veeam Backup: мгновенное восстановление ВМ из резервных копий, верификация резервных копий в автоматических лабораториях и восстановление отдельных объектов приложений. Все с интересными картинками.
Третье - очередной документ "Project Virtual Reality Check Phase IV" от Login Consultants. Вы их уже знаете по заметкам у нас тут и тут. Коллеги сравнивают производительность различных продуктов и технологий в сфере виртуализации и выкладывают результаты в открытый доступ. На этот раз сравнивались продукты для виртуализации приложений в инфраструктуре VDI: Citrix Application Streaming (XenApp), Microsoft App-V и VMware ThinApp.
Интересно, что VMware ThinApp бьет почти все остальные варианты:
Как знают администраторы систем хранения данных, у различных компонентов SAN-сети есть такой параметр как глубина очереди (Queue Depth). Он есть у HBA-адаптера сервера (на котором, например, работает VMware ESX / ESXi) и у порта Storage Processor'а системы хранения (SP). Глубина очереди определяет сколько операций ввода-вывода (IO) может быть одновременно обработано на устройстве.
Как мы уже писали, если до SP со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (T) должна удовлетворять следующему соотношению:
T >= Q*L,
где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.
Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:
T>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.
Queue Depth на серверах
По умолчанию, для хостов VMware ESX / ESXi значение Queue Depth равно 32, как его изменить, читайте у нас тут и вот тут. Теперь внимание: этот параметр имеет значение только когда у вас только одна виртуальная машина на хост-сервере использует конкретный LUN. Если его используют уже 2 машины, то он игнорируется, а в действие вступает следующая расширенная настройка (Advanced Setting - как его задавать описано тут):
Disk.SchedNumReqOutstanding (DSNRO)
Этот параметр также по умолчанию равен 32. Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN. То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в статье Jason Boche, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32:
Здесь видно, что активно выполняется 30 команд (максимально 32) для параметра DQLEN, а остальные 67 остаются в очереди. То есть параметр определяет максимальную планку в IO как для одной машины на LUN, так и для всех машин на LUN.
Важно, чтобы параметры Queue Depth и DSNRO были установлены в одно и то же значение. Это рекомендация VMware. Так что, если вздумаете изменить один из них - не забудьте и про второй. И помните, что параметр DSNRO для хоста - глобальный, а значит будет применяться ко всем LUN, подключенным к хосту.
Target Port Queue Depth на массивах
Для дискового массива (а точнее, SP) очередь - это то, куда он сладывает SCSI-команды в то время, пока обрабатывается и выполняется пачка предыдущих. Нормальный midrange-массив имеет глубину очереди 2048 и более. Если массив получает в очередь команд IO больше значения Target Port Queue Depth, то он назад выдает команду QFULL, которая означает, что очередь заполнена и хост-серверу нужно с этим что-то делать. VMware ESX / ESXi реагирует на это следующим образом - он уменьшает очередь на LUN и периодически (каждые 2 секунды) проверяет, не исчезло ли QFULL, и если исчезло, то начинает постепенно увеличивать глубину очереди для этого LUN (это может занять до одной минуты). Это и есть причины тормозов, которые часто возникают у пользователей VMware ESX / ESXi.
Как управлять очередью и адаптивный алгоритм VMware
Теперь становится понятным, почему мы сразу не выставляем параметр Disk.SchedNumReqOutstanding на хостах VMware ESX / ESXi в максимальное значение - мы можем вызвать QFULL на SP массива. С другой стороны, уменьшать его тоже нехорошо - мы ограничим количество операций IO с хоста на LUN.
Поэтому здесь нужен гибкий подход и он есть у VMware (adaptive queue depth algorithm). Работает он таким образом: мы его активируем с помощью параметров Disk.QFullSampleSize и Disk.QFullThreshold в Advanced Settings. Они влияют вот на что:
QFullSampleSize - если число число ответов QFULL (оно же BUSY) превысит его, то ESX / ESXi наполовину обрежет глубину очереди (LUN queue depth)
QFullThreshold - если число ответов о том, что QFULL или BUSY больше нет, превысит его, то ESX / ESXi будет постепенно увеличивать LUN queue depth на 1 (вроде бы, каждые 2 секунды).
Но сколько бы не уменьшалось DQLEN - ниже заданного нами значения DSNRO оно не упадет. Это защищает нас от неожиданного провала в производительности. Кстати, эти параметры тоже глобальные - так что если один (например, тормозящий) массив с хоста будет подвергаться такому адаптивному эффекту со стороны ESX / ESXi, то и для другого (например, производительного) тоже будут выполняться такие фокусы.
Теперь, что дополнительно можно почитать на эту тему:
То есть мораль всей басни такова - дефолтные зачения DSNRO и Queue Depth подходят для большинства случаев. Но иногда имеет смысл изменить их. Но в этом случае надо учитывать параметры системы хранения данных, структуру SAN, количество LUN и другие параметры, влияющие на производительность ввода-вывода.
Как вы знаете, скоро должен состояться VMworld 2011, где, скорее всего, будет объявлено о выходе VMware vSphere 5, серверной платформы виртуализации. Возможно, параллельно с этим компания VMware выпустит и новую версию продукта для виртуализации настольных ПК предприятия VMware View 5.
На сегодняшний день уже известны некоторые подробности о новых возможностях VMware View 5:
VMware View 5 будет включать в себя улучшенную версию протокола PCoIP (напомним, что во View 4.6 уже появились некоторые улучшения). На данный момент производительность протокола PCoIP существенно уступает аналогичному Citrix HDX/ICA, на базе которого построено конкурирующее решение Citrix XenDesktop. Улучшения PCoIP в VMware View 5 должны позволить VMware немного приблизиться к позициям Citrix в сфере виртуализации настольных ПК.
VMware View 5 будет иметь некий аналог технологии Citrix IntelliCache, которая появилась в платформе Citrix XenServer 5.6 SP2 (со стороны брокера соединений у Citrix его поддержка включена в XenDesktop 5 SP1). У Citrix эта технология позволяет снижать стоимость обслуживания инфраструктуры виртуальных ПК и повышать их производительность за счет использования комбинации общего и локального хранилища (с кэшированием) для виртуальных машин. VMware View 5 также получит что-то подобное.
Наконец-то VMware View 5 получит возможности Virtual Profiles - профили пользователей виртуальных ПК на базе программного продукта от компании RPO Software, приобретенного VMware. Эта возможность позволяет "отвязать" профиль пользователя от операционной системы Windows и повысить портируемость пользовательских окружений (ранее планировалось, что эти возможности войдут в состав View 4.5 или 4.6). Однако сообщается, что эта функция, скорее всего, будет включена несколько позже (но в этом году), и ее возможности будут весьма сильно урезаны по сравнению с тем, что планировалось сделать вначале.
Также о предложениях пользователей по функционалу VMware View 5 можно почитать вот в этой ветке на VMware Communities.
Мы уже писали о веб-клиенте для VMware View от компании Ericom, который построен на базе HTML5. Теперь вот вышла версия Ericom AccessNow for VMware View 1.0. Примечательной особенностью данного ПО является то, что оно позволяет получить доступ к виртуальному ПК предприятия, где развернута инфраструктура VMware View, через любой HTML5-браузер, без необходимости установки каких-либо дополнительных компонентов. Можно также будет использовать и Chromebooks ("Хромбуки" - устройства с Google Chrome OS).
То есть рабочий стол виртуального ПК можно открывать прямо во вкладке Chrome:
Основные возможности Ericom AccessNow for VMware View 1.0:
Не требует Java, Flash, Silverlight или других компонентов.
Поддерживает процессоры Intel x86, ARM и другие.
Может действовать как Gateway, предоставляя доступ к компьютерам в сети предприятия за счет публикации только одного IP.
Передача данных по SSL.
Используются техники WebSockets, AJAX, JSON и другие из HTML5.
Веб-клиент соединяется с сервером Ericom, используя Ajax и WebSockets (когда это возможно) через SSL и пробрасывает клавиатуру и мышь.
С точки зрения протокола доступа, этот клиент от Ericom использует собственный Ericom HTML Display Protocol (HDP), который несколько отличается от RDP и PCoIP (первый работает поверх WebSockets, а от последнего пришлось отказаться в силу его закрытости и невозможности реализации через HTML5).
Скачать пробную версию Ericom AccessNow for VMware View 1.0 можно по этой ссылке.
При внесении различных параметров в конфигурационные файлы виртуальной машины на VMware ESX могут возникнуть различные ошибки. При этом виртуальная машина может до некоторого времени работать корректно.
Есть способ проверить vmx-файл на предмет наличия в нем ошибок (опечаток, например, в путях к рабочим директориям и т.п.). Для этого есть команда:
/usr/bin/vmware-configcheck <путь к vmx-файлу>
Она проверяет его на соответствие правилам оформления, приведенным в файле /etc/vmware/configrules.
В случае успешной проверки результат будет таким:
А в случае неуспешной - будет выведен результат FAIL и описание ошибки конфигурации.
В первой части статьи о файлах журнала VMware ESX (логах) мы описали их размещение и назначение. Но поскольку готовящаяся к выходу платформа VMware vSphere 5 будет построена только на базе платформы VMware ESXi (см. нашу серию статей), то сегодня мы поговорим о том, где находятся логи ESXi и как их можно посмотреть.
Если открыть консоль ESXi через консоль Tech Support Mode или по SSH мы можем увидеть следующую структуру основных логов:
/var/log/vmware/hostd.log – это лог службы хоста VMware ESXi (host daemon - служба, управляющая хостом)
/var/log/vmware/vpx/vpxa.log – лог агента vCenter (который управляет через агент хоста). Этого лога не будет если ESXi работает не под управлением vCenter.
/var/log/messages – Syslog Log (это комбинация логов vmkernel и hostd)
/var/log/sysboot.log - System boot log (лог загрузчика хоста)
/var/log/vmware/aam/vmware_<hostname>-xxx.log - Automatic Availability Manager (AAM) logs (лог агента VMware HA). Этого лога не будет если ESXi работает не под управлением vCenter.
NB: Обратите внимание, что при установке VMware ESXi по умолчанию логи хранятся в разделе Scratch Partition, который находится в памяти в виде RAM-диска. После перезагрузки хоста - они будут удалены, если вы не настроили этот раздел для хранения, в том числе, логов.
Теперь как эти логи на ESXi можно посмотреть. Есть аж 5 способов.
1. Через DCUI (Direct Console User Interface).
В главном меню System Customization, куда вы попадаете по кнопке F2 на самом сервере, выберите пункт "View System Logs":
Также в DCUI можно по комбинации клавиш Alt+F12 увидеть лог vmkernel.
Также вы можете зайти в консоль и перейти в папку с логами (/var/logs):
2. Через веб-браузер.
Просто наберите в адресной строке https://<esxi ip address>/host, после чего введите имя пользователя и пароль root.
3. Использование Syslog-сервера для VMware ESXi.
Вы можете настроить Syslog-сервер для ваших хостов ESXi в целях организации удаленного логирования. Для этих целей вполне можно использовать бесплатный продукт vSphere Management Assistant (vMA). Подробно это описано тут:
Кстати, по умолчанию сообщения логов vpxa и hostd (/var/log/vmware/vpx/vpxa.log и /var/log/vmware/hostd.log) дублируются в /var/log/messages. Если вы хотите это отключить (чтобы там было меньше флуда), используйте вот эту заметку.
На сайте VMware Communities появилась в открытом доступе для всех желающих бета-версия продукта VMware Converter Standalone 5.0, предназначенного для миграции физических серверов в среду VMware vSphere, перевода виртуальных машин на эту платформу с решений других производителей (Hyper-V), а также для миграции между платформами VMware (Workstation, Server, Fusion). Слово Standalone в названии продукта означает, что он не интегрирован с консолью vSphere Client при подключении к vCenter и имеет свой собственный интерфейс управления. Напомним, что продукт абсолютно бесплатен.
Напомним также, что последняя мажорная версия VMware Converter вышла аж в 2009 году (см. нашу заметку тут, а также про версию 4.3 - тут). Поэтому данное обновление - весьма долгожданное.
Новые возможности VMware Converter 5.0:
Сохранение LVM-конфигурации томов исходной Linux-машины при ее миграции.
Улучшенный механизм синхронизации, включая запланированный запуск задачи, а также выполнение нескольких задач синхронизации в одной задаче миграции.
Оптимизация выравнивания дисков и разделов + возможность изменения размера кластера ФС.
Передаваемые данные при миграции между исходным сервером и сервером назначения - шифруются.
Поддержка миграции Red Hat Enterprise Linux 6.x (32-bit and 64-bit). Прекращена поддержка Ubuntu 5.x-7.x.
Скачать бету VMware Converter Standalone 5.0 можно по этой ссылке. Документация доступна тут.
Суть диалога блоггеров такова: Брайан рассматривает позицию VMware о собирании денег с пользователей на базе лицензирования виртуальных машин весьма скептически. Это, во-первых, весьма неудобно (сложно понять, какие машины надо лицензировать, сколько их вообще и т.п.), а, во-вторых, это становится более накладно + не толкает пользователей на оптимизацию датацентра в части увеличения коэффициента консолидации (а, как следствие, и уменьшения количества оборудования).
Так вот, Скотт ему отвечает, что переход на лицензирование по ВМ - вполне логичен. Ибо производительность процессоров на серверах растет как на дрожжах (напомним, что VMware vSphere лицензируется в настоящее время по количеству физических процессоров).
То есть, в данный момент у VMware как бы наблюдается недополученная прибыль, поскольку цена на продукты почти не меняется (хотя мы знаем, что это не так), а мощности серверных платформ растут. А недополученную прибыль как-то надо возвращать, в том числе за счет введения новых программ лицензирования.
Интересно, кстати, будут ли новые версии vSphere проходить по таким программам? Если да, то это приведет к такой путанице, что даже не все сотрудники VMware будут в курсе, как именно лицензируется продукт при определенных условиях (сейчас это иногда бывает и с Microsoft). Будут даже мудрые консультанты по лицензированию VMware.
Но расстраивает тут два момента - первый, что компания вводит все эти вещи в одностороннем порядке, без обсуждения среди пользователей и без объяснения причин, а второй - реально, товарищи, вмваре дорогая, очень дорогая. И безо всяких там изменений. А видно, что изменения эти будут только в сторону удорожания.
Как оказалось, на нашем сайте нет хорошего руководства по назначению и использованию RDM-дисков (Raw Device Mapping) с платформой VMware vSphere. Постараемся заполнить этот пробел.
Давайте начнем с того, что для виртуальных машин на серверах VMware ESX есть всего 3 типа дисков с точки зрения виртуализации подсистемы хранения:
VMDK-диски
Это самые часто используемые диски VMware vSphere. Они создаются на хранилищах VMFS или NFS и позволяют использовать все возможности работы VMware с виртуальными машинами в части распределенных служб. К ним относятся распределенная блокировка файлов (distributed file locking), снапшоты дисков, vMotion - и много чего еще. О типах виртуальных дисков у нас есть отдельная статья. Обычные vmdk-диски - это самый высокий уровень виртуализации, т.е. все SCSI-команды виртуальной машины при обращении к нему проходят через компонент VMkernel, который уже процессит их внутрь файла vmdk. За пределы этого файла виртуальная машина ничего не видит. То есть виртуальной машине дается кусочек тома VMFS или NFS в виде файла vmdk, операции по работе с которым полностью контролируются гипервизором - это и есть максимальная виртуализация устройства. Из этого, кстати, следует, что поскольку есть слой виртуализации, в определенных условиях такие диски могут работать медленнее RDM-дисков, но есть также и условия при которых такие диски могут работать быстрее. Более подробно об этом можно прочитать здесь. На этих дисках в статье мы останавливаться не будем.
RDM-диски в режиме виртуальной совместимости (virtual RDM).
Это промежуточный тип диска с точки зрения виртуализации хранения. В случае создания такого диска на хранилище VMFS (NFS - не поддерживается) создается mapping-файл (он тоже с расширением *-rdmp.vmdk), через который происходит маппирование виртуальной машине физического дискового устройства LUN. Устройство это маппируется особым образом - основные служебные операции по работе с ним (например, команда Open и другие служебные SCSI-команды) проходят через через слой виртуализации в гипервизоре, а команды по работе с данными (Read и Write) процессятся напрямую к устройству, минуя слой виртуализации.
Что означает, что передаются напрямую только команды Read / Write в виртуальный RDM? Это означает, что устройство представляется виртуальной машине как обычный SCSI-диск, с которым нельзя работать иначе как с устройством хранения (как можно иначе - дальше). Зато сохраняется большинство возможностей VMware vSphere по функциональности - например, снапшоты. Ниже мы также посмотрим, где можно использовать такой тип дисков.
RDM-диски в режиме физической совместимости (Physical RDM). Это наименее виртуализованный тип дисков. Для таких дисков хост-сервер ESX также создает mapping-файл, но вот iSCSI-команды процессятся к устройству LUN напрямую, минуя слой виртуализации хранилища в гипервизоре (за исключением одной команды LUN Report).
Что дает такой механизм доступа к устройству? Он позволяет использовать iSCSI-устройство не просто как диск, но и передавать к нему различные iSCSI-команды, которые предоставлют больше возможностей по работе с устройством (например, управление SAN-устройствами изнутри виртуальной машины или снятие снапшота на уровне хранилища). Ниже мы тоже рассмотрим подобные примеры.
Общее у всех этих продуктов - то, что они лицензируются не на базе процессоров (как vSphere), а на базе виртуальных машин. Эта особенность, с одной стороны, как бы ближе к облачной концепции - типа нам не важно где и как работают виртуальные машины, а важно сколько сервисов мы используем, соответственно, за них и платим.
Но с другой стороны, с этим возникают специфические проблемы, на которые обратили внимание в блоге компании VKernel. Суть проблем такова:
Когда организация использует модель лицензирования по физическим процессорам, ее основная цель - достичь максимальной консолидации виртуальных машин на хосте, поскольку она платит за инфраструктурные составляющие (стойки, питание, охлаждение, площади), а также за весьма недешевые лицензии на продукты для виртуализации. А вот когда лицензируются виртуальные машины - увеличение коэффициента консолидации не сказывается на стоимости лицензий, а значит нет и соответствующей мотивации у администраторов и менеджеров датацентра.
Когда используется лицензирование по числу виртуальных машин - это очень сложно учитывать. Виртуальные машины постоянно создаются, удаляются, развертываются в тестовых целях и забываются. Учитывать число лицензий в таких окружениях очень сложно и затратно.
Также автор обратил внимание на проблему, изложенную на одной из веток комьюнити, где у человека возникли проблемы с применением продукта CapacityIQ - он пытался строить отчеты о емкостях инфраструктуры не для всех виртуальных машин (поскольку некоторые не должны влиять на ее будущее состояние). Но оказалось в продукте нет такой возможности - он собирает информацию со всего окружения vCenter и нам рекомендуют лицензировать виртуальных машин столько, сколько нам реально нужно в анализе. Однако это очень неформализованное правило, которое нельзя отразить в EULA.
То есть, в данном случае совсем непонятно, какие виртуальные машины нам надо лицензировать (если она работает раз в году - надо?). Подобные проблемы в будущем будут возникать и в других продуктах (просто вышеозначенные - пока весьма не распространены). А это плохо, вот.
Компания VMware сделала очередной документ по сравнению своей платформы виртуализации VMware vSphere 4.1 с ближайшими конкурентами Microsoft Hyper-V R2 SP1 и Citrix XenServer 5.6 FP2 (то есть, с самыми последними релизными версиями вышеозначенных продуктов на сегодняшний день).
Мы представляем его адаптированную версию (кликабельно):
Надо сказать, что при всей необъективности подобных сравнений, они все же несут некоторую пользу. С помощью таких табличек удобно устраивать дискуссию со сторонниками и противниками тех или иных продуктов и технологий виртуализации. Они позволяют держать ключевые пункты в голове и на столе.
Кстати, обратите внимание, что появились новые пункты про облачные вычисления и IaaS. С Citrix OpenCloud, про который мы недавно писали, еще ничего не ясно.
В продолжение темы "Как сбросить пароль root на VMware ESX". У Dave Mishchenko есть отличная инструкция о том, как сбросить пароль пользователя root на хосте VMware ESXi в том случае, если вы его потеряли, забыли или съели. Работает эта инструкция и для VMware ESXi 4.1 (а также 4.0 и даже 3.5). Переведем ее вкратце.
1. Допустим хост VMware ESXi у вас сейчас работает и вы можете выполнять на нем команды локально или по SSH. Тогда имеет смысл выполнить команду:
cat /etc/shadow
Видим картинку с хэшем пароля рута:
Хэш пароля - это то, что написано после root : до следующего двоеточия (само двоеточие не включается). Хэш этот нужно записать на случай, если его понадобится восстановить назад.
2. Дальше нужен какой-нибудь Linux live CD. Предлагается использовать Slax Linux Live CD.
Далее просматриваем смонтированные разделы сервера ESXi командами:
fdisk -l (смотрим подходящие FAT16 разделы, где у нас размещен загрузчик)
ls -l /mnt/sda5/ (основной, при загрузке монтируется как /bootbank)
ls -l /mnt/sda6/ (резервный, при загрузке монтируется как /altbootbank)
В случае чистой установки ESXi, картина будет такова:
Нас интересует файл state.tgz - там все, что нам нужно. Если у вас ESXi Embedded то нужен файл local.tgz (который в первом случае находится внутри state.tgz).
Распаковываем сначала state.tgz, а потом local.tgz командами gzip и tar во временную директорию. Далее заходим в ней в папку /etc и открываем в ней файл shadow командой:
vi shadow
У вас откроется что-то вроде того:
Теперь посмотрите на картинку ниже, мы удаляем хэш пароля из этого файла:
То есть убираем все то, что между двумя двоеточиями. Выходим из файла, сохранившись.
Теперь все это упаковываем назад, для чего во временной папке (туда надо подняться из /etc) выполняем такую команду (апдейтим архив изменившейся папкой):
tar -czvf local.tgz etc
Если вы используете ESXi Embedded - кладете файл local.tgz на место, откуда брали. Если обычный ESXi - снова апдейтим архив:
tar -czvf state.tgz local.tgz
И также копируем туда, где он лежит:
Перезагружаем сервер и уже загружаемся в VMware ESXi. Видим такую картинку:
Это значит - все получилось. Теперь можем заходить в консоль под пользователем root с пустым паролем. Вот такой незамысловатый способ сброса пароля на хосте VMware ESXi.
Те, кто увлекается разработкой сценариев на PowerShell на фреймоврке PowerCLI, наверное помнят про бесплатную раздачу постеров на блоге VMware. Тогда не все успели забрать свой постер.
Сейчас они пишут, что раздача закончена. Но не беда - вы без проблем можете забрать свой постер по PowerCLI по этой ссылке. А вот еще версия для распечатки на листах А4.
Примите участие в форуме VMware, чтобы узнать, каким образом компания VMware, международный лидер в области виртуализации и облачной инфраструктуры, и наши партнеры предоставляют решения для облачной инфраструктуры и управления, которые значительно снижают сложность ИТ-среды, повышают уровень безопасности и ускоряют процессы создания, развертывания и запуска приложений.
RSS
